Aminet 1 (Walnut Creek)/Aminet - June 1993 [Walnut Creek].iso/ab20/sounds/tools/edplayer.lzh/EdP.history.README

Text File | 1991-11-03 | 13KB | 216 lines

----------------------------------------------------------------------------
A History of changes to EdPlayer.  All previous users, PLEASE read this
file to see what's new!!
----------------------------------------------------------------------------
EdPlayer v1.1a: 11/03/91
    Oops!!  Version 1.1 broke EdPlayer's compatability with people using
OS 1.3 with an overscanned screen.  This version fixes that bug.  Also
this version allows the iconified window, which stretches to the left when
printing long filenames in large fonts, to also stretch to the right if
it can't go any further left.
----------------------------------------------------------------------------
EdPlayer v1.1:  10/25/91
    This is just a minor update to 1.0.  I kinda rushed it out, because
some bugs needed fixing right away.  Also some useful stuff added.
* req.library added.  If EdPlayer can't open kd_freq.library, it will
  look for req.library.  I'm also thinking about the posibility of asl...
* powerpacker.library added.  If you were using PowerPatch for EdPlayer
  alone, you can remove it from your startup-sequence, as I suspect
  EdP will be much more effecient WITHOUT it.  Also you can see neat
  messages like ...LOADING CRUNCHED... and ...DECRUNCHING... if you're
  NOT using the patch.  A new AREXX command, "DCOL", allows setting of
  the decrunch effect.
* New AREXX command "ERAS" allows erasing the program.
* ARexx commands are no longer case-sensitive.  I guess this is kind of
  a frill, but I like it better this way.  NOTE: the "MIDL" command
  still NEEDS a case-sensitive parameter for midi_dest.
* Can load PP encrypted (password protected) modules.  Will bring up a
  password requester when needed.  Also passwords can be entered via
  ARexx, see LOAD and JUKE in the DOCs for an explanation...
* Iconified window now supports bigger fonts
* Iconified window now has NAME of current song!  Also scrollbar has a
  new trick that puts the song name there after a scroll.
* PAL/Overscanned WB screens supported better.  EdPlayer 1.0 used to open
  in the NTSC, no overscan position all the time.  EdP 1.1 tries to
  center itself, and appear flush with the bottom.
* FADE bug fixed.... NOT!!!!  This is NOT a BUG!  PLEASE read the DOCs
  in the BUTTONS section under FADE for a NEW & IMPROVED description
  of why EdPlayer fades the way it does!!  The FADE code didn't change.
* Slight bug in program mode made it impossible to enter songs with
  European characters in the names (like ü, ä, etc.).  This is now
  fixed.  Never do signed arithmetic on ASCII bytes...  >127 looks neg :-)
Hmm, now that I look at it, it doesn't seem like such a "minor" update
after all...  oh well...
----------------------------------------------------------------------------
WISH LIST:
     Before reporting a suggestion, please make sure it's not in the wish
list.  If it's not, then report it!
The following is a wish list of features that MIGHT OR might NOT appear in
a future version of EdPlayer:

* I wish EdP supported ASL.library
* I wish EdP could override the audio filter
* I wish EdP had FastForward/Rewind buttons like IntuiTracker
* I wish EdP had user-definable defaults for PAL/NTSC, FADE, etc.
* I wish EdP had a random-play program mode.
* I wish EdP could switch the VU meters for novice users 1234 ==> 1432
               so that the left/right speakers go like:  LRRL ==> LLRR
* I wish EdP worked on ALL A3000s, AAAARGH!!!
* I wish EdP could support MED song+samples format $*#&^*!!!
And don't forget:
* I wish EdP supported ProTracker and MED 3.20!  (hint!!)  ;-> !!!!
----------------------------------------------------------------------------
EdPlayer 1.0: Sometime in July 1991, I think.
   New features in EdPlayer 1.0:

* All of them.

Well what did you EXPECT???  duh!
----------------------------------------------------------------------------

Well that ends the useful part of this file.  Now for the entertaining
part.  Only read on if you have some time and want to hear a good story...

============================================================================

                    THE HUNT FOR THE MEMORY MONSTER

============================================================================

     The following is a true story of what happened to me as I tried to
debug EdPlayer.  Some scenes depicted may be insutable for inexperienced
programmers or sensitive coders.  Reader discretion is the recommended
default configuration.

                              * * * *

     There I was, sitting at home on my summer vacation, with nothing
better to do in my life than work on EdPlayer.  One of the things that
prompted me to write EdPlayer in the first place was the total lack of
any mod player that was RELIABLE and had ALL the features I wanted in ONE
program (including ARexx).  This is probably why I was turning red and
looking around for a nice brick that would fit in my monitor.
     EdPlayer was not working.
     All the features I really hated -- the way IntuiTracker crashes during
serial port activity, the way XTPlay fragments the memory beyond belief
after playing an unknown number of modules -- ALL of these features were
things I NEVER wanted to see in one of MY programs.  They were some of the
main reasons I was writing EdPlayer, after all!  And yet, there they were.
They were just sitting there in EdPlayer v0.8, fragmenting my CHIP RAM down
to 2K blocks if I played the MegaBall high score tune, GURUing my machine
if I used the modem, and really annoying me like no bug had annoyed before.
     But I had been CAREFUL!!  I checked and double-checked all my
allocations and de-allocations.  So I loaded the thing into my debugger.
The bug refused to happen in trace mode, so I tried running it with
breakpoints in it.  Still the bug didn't appear.  So I just ran the thing
with no breakpoints and no stopping...  The bug appeared!  "AHA!  Now I've
got you!!" I yelled at the hex dump on my screen.  I rebooted (the bug
forced me to do that... it kinda gurus!)  I tried the breakpoints again
without success.  Then I tried it no stopping again.  The bug was GONE!  It
wouldn't appear anymore!  "It's FIXED!!!" my brother cheered, but I told
him that I hadn't done ANYTHING, and the bug was STILL THERE.  I
demonstrated outside of the debugger.  Yup, still there.
     A few days of letting the debugger tourture me just made things worse.
Every now and then, the bug would appear briefly, and when I moved the
debugger in for the kill, screaming "AHA!  Now I've got you!!" at every
chance, the bug would disappear like magic.  Worse yet, the bug was making
its appearences less and less frequently, as if it were "learning" how to
avoid me.  I know it sounds unreal, but it felt real enough...
     I couldn't look directly AT the bug.  But maybe I could see its
footprints in the system...  I wrote down the GURU number and address,
which turned out to be the SAME each time the bug struck.  It was always an
unaligned address error, at the same ROM location every time.  Was EdPlayer
misusing an OS function?  Nope.  The bug struck OTHER programs, and didn't
even affect EdPlayer!  "Maybe it's not EdPlayer's fault," my mom suggested.
But by now I had stopped using the debugger, and from CLI, I was able to
generate LOADs of bugs, rebooting after each one.  I showed my mom the
basic pattern:  Open a shell.  RUN EDPLAYER.  Type "avail".  See your
free memory.  LOAD a song into EdPlayer.  Type avail, see memory.  Press
PLAY, and quickly type avail again.  See avail's opening banner.  See
SOFTWARE FAILURE -- TASK HELD.  EdPlayer continues to function, as if
nothing were wrong.  The gadgets work and all.  EdPlayer 0.8 was a task
masher!
     A few weeks of this got me really steamed.  I had disassembled the
area of ROM in question down to the bare bits.  It turned out to be Exec's
AvailMem() command, which was natural since "avail" was dying all the time.
I don't know the legal technicalities of disassembling ROMs, but I figured
since I wasn't giving it to anyone, it was OK.  It turned out that as
AvailMem() tried to compute the LARGEST free block of CHIP mem, it has to
ride down a chain of MemChunks, and hits an unaligned chunk at 0xffffffff!
     But it GETS WORSE...  I wrote a little prog to find the LARGEST CHIP
block without using AvailMem(), by directly following the MemChunks and
testing each one for odd addresses, printing them all out when it's done.
(I'm _NOT_ distributing this program, as it looks a bit too similar to
those ROMs...)  Anyway, now I could issue "myavail" at a CLI and not worry
about a GURU.  Here comes the scary part folks!
     The Amiga's memory list is GLOBAL.  That is, there is only ONE list
for the ENTIRE machine.  But I opened two shells and ran EdP 0.8 from one
of them, and tried myavail in both shells, and then I saw it.  I couldn't
believe my eyes!!  The myavail in EdPlayer's shell clearly showed the
mangled, unaligned chunks.  The myavail in the OTHER shell showed a
perfectly clean memory list!  I tried typing the command in both shells,
over and over, in random order.  I tried rebooting dozens of times.  The
results were the same:  The GLOBAL memory list looked DIFFERENT depending
on which dos process looked at it, with the same viewing program!!!!  One
list was destroyed, and the other was fine!  But there's ONLY ONE LIST!!!!!
#include <twilight_zone.music>
     The BUG had earned itself the nickname of "The Memory Monster."  It
was driving me nuts.  I was going out of my mind.  "Why don't you just
release EdPlayer?" my brother asked.  I looked at him, horrified.  "Lots of
module players do weird things with the CHIP ram," he explained.  I was
about to tell him what I thought of his comment, when suddenly I thought
about his comment:  "LOTS of module players"... HMMMMMM............
     That was it.  It was SO obvious.  There was no bug in *MY* code!
There was some kind of major flaw in the actual module-playing code that is
used by LOTS of module players!  "AHA!  Now I've got you!!"
     Several more weeks went by as I heaped on more and more debugging and
monitoring code to the player routines, mostly mt_init since the problem
appears at the start of a song.  By this time I was taking a summer math
course at Lehigh, but luckily I had my Amiga with me so I didn't go insane
(well, not completely insane, anyway).  I had mt_init keep a table of
memory writes.  First in the table was the module's starting address, and
next was the ending address (start+size).  All the entries after that
were places in memory that mt_init was writing, which I was hoping would be
out-of-bounds at some point.  I was hoping to do some REALLY slick code to
keep mt_init from going out-of-bounds.  But I was in for more torture:  The
table didn't seem to have any illegal entries!!  So where was my Monster???
     I had to put it aside for a few days.  I just couldn't take it.  I had
been chasing this thing for so long, and at EVERY step of the way, the
Monster seemed to learn new tricks and find new places to hide.
     Then, right in the middle of class one day, an idea poped into my
head.  It was a last chance, but I had a good feeling about it.  After
class, I came straight home.  I approached the Amiga.
#define SPEED (slow_motion)
     My hard drive whined as it gained speed and saw the size of my
startup-seqence.  I calmly waited for a chance to launch the debugger.
#include <terminator_style.music>
     I looked again, much more closely, at the list of mt_init memory
writes.  In particular, I examined the last entry in the list.  The last
entry exactly MATCHED the module ending address.  But the so-called ending
address was computed with (start+size), a computation that produces the
first memory location AFTER the real end of the module.  There it was:
mt_init was writing JUST past the end of the mod, in a very camouflaged
way.  I stood there, looking at my much-hunted foe for the first time.  A
slight grin flickered across my face.
#include <hasta_la_vista_baby.8SVX>
     The Memory Monster never had a clue what hit it.  It was dead before
it could say "GURU."  It was a quick and painless death, and when the smoke
and dust had cleared, I was just a little bit disappointed.  I had been
hoping to do some really fancy code to kill the monster.  Instead, all I
got to do was allocate 4 more bytes of mem than the module size needed, to
hold the extra memory write (which I assume is important for something, and
therefore I should allocate mem to catch it).  Well, I allocated 8 bytes
just to be on the safe side, but it was still a bit of a let down.
     But what was I sad about?  The Memory Monster, after months of
torturing me, was finally dead at my feet.  The memory fragmenting, the
serial port crashes, ALL the weirdness disappeared.  All of those
"different" bugs were merely the many manifestations of the Memory Monster.
It was all behind me now, all fixed.  I felt pretty good.  EdPlayer's
version number was bumped up to 0.9, and after some finishing touches, it
became 1.0 and got released.
#include <standing_ovation.h>
============================================================================
EdPlayer v1.0 got me a whopping total of $30 in donations.  yippie

                                                  --Ed.